前言

時間過得很快，距離2019鐵人挑戰賽將近一年了，在這一年間除了持續進行android程式設計的開發之外，也接觸了不少新東西！例如：重構、實作模式、測試驅動開發、kotlin、資料科學概念、python、機器學習等等，在眼界跟技術方面都有某部分的成長。

在去年的鐵人挑戰賽 MVC模式、 MVP模式、 MVVM模式，這三種程式架構，是我一直想藉機希望有更深入了解的，不過因為工作生活等等各種繁雜事物(?)，一直拖欠到今天，而且現在也在猶豫要不要參加今年的鐵人賽，所以先寫一篇小文章練練文感哈。

定義

首先先介紹一下MVC模式，我們先看一下wiki上的定義

MVC模式最早由Trygve Reenskaug在1978年提出[1]，是全錄帕羅奧多研究中心（Xerox PARC）在20世紀80年代為程式語言Smalltalk發明的一種軟體架構。MVC模式的目的是實現一種動態的程式設計，使後續對程式的修改和擴充簡化，並且使程式某一部分的重複利用成為可能。除此之外，此模式透過對複雜度的簡化，使程式結構更加直覺。軟體系統透過對自身基本部分分離的同時也賦予了各個基本部分應有的功能。

— wikipedia MVC

Wiki上的定義算是蠻清楚的，但是如果運用在實際開發上呢？因為我對Android開發比較熟悉，用Android開發做為例子說明。

因為在Android開發中創立專案資料夾設計的關係，基本上算是Android開發中預設的模式，在使用上目前是最為直觀和容易理解的，把程式碼切分為Model、View、Controller這三種角色。

• Model 負責存放資料
• View 負責畫面的部分
• Controller 負責畫面與資料間的溝通

將MVC架構，經由圖示化呈現的話程式會像下面這樣 —

圖示看起來算是蠻清楚容易使用的，實際用起來也是沒有什麼大問題，很適合在小專案或是短期的開發上使用，但是如果開發專案週期一長，程式碼堆積起來的話就會發現致命缺點。

MVC模式使用在Android開發上，在程式經過一定的開發週期後，由於Controller負責了整個程式的邏輯部分，不可避面的會發生Controller變得非常肥大的狀況出現，也因為這樣使得程式碼的修改和維護變的相對困難很多。

程式碼肥大這種狀況也出現在其他語言和專案開發上，例如使用 Java進行網頁開發的 Servlet/JSP，和使用 Python和 django框架的網頁開發，這幾種程式開發的共通點是 View和 Controller中有高度的耦合，所以在專案開發最後，程式碼發生難以修改和測試驗證的狀況。

另外因為架構設計已經有些歷史，這類MVC架構有個不怎麼出名的名稱叫做Model 2，有興趣的同學可以讀讀這篇文章分享。

MVP模式

在查詢各種資料之後，我認為MVP模式是MVC模式的一種變種，和MVC模式相當相似，定義也相對比較模糊，所以我認為MVP模式可以視為是廣義的MVC模式來理解，將Controller的任務做或是變換，使得專案架構有一致性。

MVVM模式

MVVM模式是比較有特色的模式並且相當實用的，將View和Model綁定為ViewModel，使得資料的變換和UI的變換同時發生，並且減少所需要撰寫的程式碼數量。

將MVVM架構，經由圖示化呈現的話程式會像下面這樣 —

可以看到圖示化之後和MVC模式非常相識，而原本的Controller位置，換為ViewModel呈現，並且實現與Model的資料綁定，藉此使得專案更為乾淨，不用寫一大堆主動更新View的程式碼。

結論

時間演進之後，出現了很多不同的專案架構設計，並沒有最好的架構，而這些設計最為根本的還是為了實現客戶需求和完成專案而存在的，在不同的需求和專案中，使用最為方便和快速實現功能的架構，或是更為嚴謹的架構，都有其優缺點存在，理想的狀態是根據不同的狀況而使用不同的架構。

舉個例子來說，在開發只有兩三頁的測試用小專案時，就不用太糾結一定要用哪一種模式，使用最熟悉並且好上手的架構進行開發就可以了，當然如果是專門用來練習架構的專案例外囉～

關於架構每個人的看法都會有點不一樣，在這篇文章提供一下自己的看法，拋磚引玉，希望對大家能有一些幫助，如果有什麼意見也歡迎提出～